4 Requirements Engineering
	Know what you want before starting
	WHAT the system does
	(NOT how system is implemented)
	Feasibility
	Go/no go

	Requirements should NOT pre-define solution
	High level (user) detailed (system)

Functional requirements
	What the system does (NOT how)
	Natural language
	(structured English, charts)
	Watch for ambiguity
	If off the shelf, information requirements
	Often must refine
Non-functional requirements
	Can be critical!
	Constraints
	How efficient
	How cost effective
	How reliable, available, security, confidential, 
	Response, memory used….
	May affect overall system, or certain parts
	Standards
	Product
	External (privacy etc)
	Needs to be verifiable/textable
	Requirements can interact
Good fast cheap (pick one)
(at most one maximize, at most one constraint)

Processes
	Get requirements
	(tend to change)
	Specifications (what you need)
		Prioritize
		Negotiate/compromise/consultation
		Document
	Validation
	Repeat as needed
Elicitation
	Interview, observe, questionnaire
	Check documents
	Stake holders may not be able to articulate
	(users) May not understand feasibility
	(S.E.) may not understand domain
	Political factors
	Economics can be dynamic
	Different viewpoints may conflict
		Patient, Doctor, nurse, counsellor, pharmacist….
 insurance company
	resistance
	negotiate/compromise/consult
	watch for jargon
	official is not always actual!

Specification
	(of system functionality)
	Clear, understood, complete, consistent
	System may interact with other systems
	May need structure to do specifications
	Standardized format of language
	Mandatory versus desirable
	Include rationale
	Tables, graphs, charts (chapter 5 use cases)
	Produce requirements document
Validation
	(make sure what you have is correct)
	Early discovery -> less work
	Validity
	Consistency
	Completeness
	Realistic (feasible)
	Verification (test data)
Reviews
Prototype/mockup/production
Test cases

Requirements Change
	Environment changes
	Market changes
	Adding a system can actually change the environment
	Who pays who does the work (don’t always agree)
	Diverse stakeholders

Requirements management planning
	Identify requirements (change)
	Must manage the change
		Prioritize
		Tractable/feasible
		Tool support
Requirements change planning
	Problem/proposal
	Analysis
	Costing
	Implementation